METHODS AND SYSTEMS FOR AUTOMATIC VERIFICATION OF 
SPECIFICATION DOCUMENT TO HARDWARE DESIGN 



TECHNICAL FIELD 

[001] Embodiments generally relate to hardware design verification 
methods and systems. Embodiments also relate to methods and systems for 
verifying integrated circuit designs. Embodiments additionally relate to Power 
On Self Test (POST) techniques and devices. 

BACKGROUND OF THE INVENTION 

[002] In many instances it can be necessary to implement hardware 
design verification methods and systems. The objective of design verification is 
to ensure that errors are absent from a design. Modern integrated circuit (IC) 
manufacturing technology is enabling IC designers to place millions of 
transistors on a single IC. Design complexity is doubling every 12-18 months, 
which causes design verification complexity to increase at an exponential rate. 
In addition, competitive pressures are putting increased demands on reducing 
time to market. 

[003] Today's design flow begins with a hardware specification 
document for the design. The engineer then implements the design in a 
language model, typically a Hardware Description Language (HDL). Such a 
model can be utilized to discover incorrect input/output (I/O) behavior through a 
stimulus in expected "results out" paradigm at the top level of the design. 

[004] By far the most popular method of functional verification today is 
simulation-based functional verification, which is widely utilized within the digital 
design industry as a technique for detecting defects within hardware designs. A 
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very wide variety of products are available in the market to support simulation- 
based verification methodologies. However, a fundamental problem with 
conventional simulation-based verification approaches is that they are vector 
and test bench limited. 

[005] Simulation-based verification is driven by a test bench that 
explicitly generates the vectors to achieve stimulus coverage and also 
implements the checking mechanism. Test benches create a fundamental 
bottleneck in simulation-based functional verification. In order to verify a design 
hierarchy level, a test bench must be generated for it. This creates verification 
overhead for coding and debugging the test bench. Hence, a significant amount 
of expensive design and verification engineering resources are needed to 
produce results in a cumbersome and slow process. 

[006] Several methods have been attempted by Electronic Design 
Automation (EDA) companies today in order to address the shortcomings of 
simulation. However, none of these attempts address this fundamental limitation 
of the process. For example, simulation vendors have tried to meet the 
simulation throughput challenge by increasing the performance of hardware and 
software simulators thereby allowing designers to process a greater number of 
vectors in the same amount of simulation time. While this does increase 
stimulus coverage, the results are incremental. The technology is not keeping 
pace with the required growth rate and the verification processes are lagging in 
achieving the required stimulus coverage. 

[007] Formal verification is another class of tools that has entered the 
functional verification arena. These tools rely on mathematical analysis rather 
than simulation of the design. The strong selling point of formal verification is 
the fact that the results hold true for all possible input combinations to the 
design. However, in practice this high level of stimulus coverage has come at 
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the cost of both error coverage and particularly usability. While some formal 
techniques are available, they are not widely used because they typically require 
the designer to know the details of how the tool works in order to operate it. 
Formal verification tools generally fall into two classes: (1) equivalence 
checking, and (2) model checking. 

[008] Equivalence checking is a form of formal verification that provides 
designers with the ability to perform RTL-to-gate and gate-to-gate comparisons 
of a design to determine if they are functionally equivalent. Importantly, 
however, equivalence checking is not a method of functional verification. 
Rather, equivalence checking merely provides an alternate solution for 
comparing a design representation to an original golden reference. It does not 
verify the functionality of the original golden reference for the design. 
Consequently, the original golden reference must be functionally verified using 
other methods. 

[009] Model checking is a functional verification technology that requires 
designers to formulate properties about the design's expected behavior. Each 
property is then checked against an exhaustive set of functional behaviors in the 
design. The limitation of this approach is that the designer is responsible for 
exactly specifying the set of properties to be verified. The property specification 
languages are new and obscure. Usually the technology runs into capacity 
problems and the designer has to engage with the tools to solve the problems. 

[0010] There are severe limits on the size of the design and the scope of 
problems that can be analyzed. For example, the designer does not know which 
properties are necessary for complete analysis of the design. Further, specifying 
a large number of properties does not correlate well with better error coverage. 
Consequently, model checking has proven to be very difficult to use and has not 
provided much value in the verification process. 
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[0011] In view of the foregoing it would be desirable to create a 
verification methodology to create high quality designs and to increase the 
productiveness of design engineers by minimizing the tool setup effort and 
report processing effort. It is particular desirable to implement a method and 
system for hardware design verification, which is automatic in nature, and is tied 
directly to the original hardware design specification at the time of an actual 
hardware Power On Self Test (POST). 
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BRIEF SUMMARY OF THE INVENTION 



[001 2] The following summary of the invention is provided to facilitate an 
understanding of some of the innovative features unique to the present 
invention and is not intended to be a full description. A full appreciation of the 
various aspects of the invention can be gained by taking the entire specification, 
claims, drawings, and abstract as a whole. 

[0013] It is, therefore, one aspect of the present invention to provide 
improved hardware design verification methods and systems. 

[0014] It is another aspect of the present invention to provide improved 
methods and systems for verifying electrical integrated circuit (IC) designs. 

[0015] It is yet another aspect of the present invention to provide accurate 
methods and systems for verifying a hardware specification of integrated circuit 
(IC) designs. 

[001 6] The aforementioned aspects of the invention and other objectives 
and advantages can now be achieved as described herein. Methods and 
systems for automatically verifying a hardware design based on a hardware 
specification document are disclosed herein. A plurality of predefined elements 
can be designed within a hardware specification document, wherein the 
hardware specification document provides a hardware design for a hardware 
device. The plurality of predefined elements can be stored within a database of 
hardware components, wherein each predefined element of the plurality of 
predefined elements is associated with a hardware component of the hardware 
device. Physical components of the hardware device can be compared with the 
predefined elements maintained within the database of hardware components 
upon an initial power-up of the hardware device in order to verify that the 
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hardware device functions according to the hardware specification document. 
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BRIEF DESCRIPTION OF THE DRAWINGS 



The accompanying figures, in which like reference numerals refer to 
identical or functionally-similar elements throughout the separate views and 
which are incorporated in and form part of the specification, further illustrate 
embodiments of the present invention. 

[0017] FIG. 1 illustrates a block diagram of a data processing system in 
which an embodiment of the present invention may be implemented; 

[0018] FIG. 2 illustrates a high-level flowchart depicting logical operational 
steps, which may be followed to implement an embodiment of the present 
invention; 

[0019] FIG. 3 illustrates a high-level flowchart depicting continuing logical 
operational steps of the flowchart depicted in FIG. 2, in accordance with an 
embodiment of the present invention; 

[0020] FIG. 4 illustrates a block diagram of a hardware interrupt system, 
which can be implemented in accordance with an embodiment of the present 
invention; 
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DETAILED DESCRIPTION OF THE INVENTION 



[0021] The particular values and configurations discussed in these non- 
limiting examples can be varied and are cited merely to illustrate an 
embodiment of the present invention and are not intended to limit the scope of 
the invention. 

[0022] With reference now to the figures, and in particular with reference 
to FIG. 1, a block diagram of a data processing system 100 in which the present 
invention may be implemented is illustrated. The depicted example is not meant 
to imply architectural limitations with respect to embodiments of the present 
invention, but is presented for general illustrative and edification purposes only. 

[0023] Data processing system 100 can employ a peripheral component 
interconnect (PCI) local bus architecture. Although the depicted example 
employs a PCI bus, other bus architectures such as Micro Channel and ISA 
may be used. A Processor 102 and a main memory 104 can be connected to 
PCI local bus 106 through PCI bridge 108. PCI bridge 108 also may include an 
integrated memory controller and cache memory for processor 102. 
Alternatively, a controller 103 can communicate with PCI local bus 106 to 
provide additional architectural support. Controller 103 may be utilized in place 
of to complement an integrated memory controller and cache memory for 
processor 102. 

[0024] Additional connections to PCI local bus 106 may be made through 
direct component interconnection or through add-in boards. In the depicted 
example, local area network (LAN) adapter 110, host bus adapter 112, and 
expansion bus interface 114 are connected to PCI local bus 106 by direct 
component connection. In contrast, audio adapter 116, graphics adapter 118, 
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and audio/video adapter (A/V) 119 are connected to PCI local bus 106 by add-in 
boards inserted into expansion slots. Expansion bus interface 114 provides a 
connection for a keyboard and mouse adapter 120, modem 122, and additional 
memory 124. Host bus adapter 112 provides a connection for hard disk drive 
126, tape drive 128, and CD-ROM 130 in the depicted example. 

[0025] Typical PCI local bus implementations will support three or four 
PCI expansion slots or add-in connectors. The depicted example includes four 
loads on the mother board and three expansion slots. Those of ordinary skill in 
the art will appreciate that the hardware in FIG. 1 may vary. For example, other 
peripheral devices, such as optical disc drives and the like may be used in 
addition to or in place of the hardware depicted in FIG. 1. 

[0026] Turning now to FIG. 2, a high-level flowchart 200 depicting logical 
operational steps is illustrated, which may be followed to implement an 
embodiment of the present invention. FIG. 3 illustrates a high-level flowchart 
300 depicting continuing logical operational steps of the flowchart 200 depicted 
in FIG. 2, in accordance with an embodiment of the present invention. In FIGS. 
2 and 3, like parts or elements are indicated by identical reference numerals, 
such that flowcharts 200 and 300 represent a single continuous flowchart of 
logical operation steps. FIGS. 2 and 3 together generally illustrate a 
methodology that includes document parsing software utility, routines, and/or 
subroutines which search for predefined flags and formatting in a hardware 
specification document and extracts the hardware information from the 
hardware specification document. 

[0027] The document parsing software utility generates a database can 
be utilized by other utilities. The methodology of FIGS. 2 and 3 can also be 
utilized to implement an RTL code auto-generation utility that reads the 
database and creates valid RTL hardware description code that defines the 
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storage elements in the hardware. Additionally, a software code auto- 
generation utility can be utilized to read the database and create valid software 
code that defines accesses to the storage elements in the hardware, and which 
also can generate hardware specification tables, which can be utilized by a 
Power On Self Test (POST) function, which is described in further detail herein. 

[0028] Thus, as depicted at block 202, the process is initiated. 
Thereafter, as illustrated at block 204, a document writer can follow a specified 
procedure to created detailed descriptions of the hardware to be designed 
according to the hardware specification document. Such specified procedure 
includes the use of specified formats for register map tables, address map 
tables and register description sections of the hardware specification document. 
Next, as described at block 206, invisible flags are embedded in the document 
to be utilized by the document reader script, which will be described in more 
detail herein. Thereafter, as depicted at block 208, the document can be saved 
and used by internal and external engineers as formatted. Next, as illustrated at 
block 210, the document can be saved as a text-only document for use by the 
document reader script. 

[0029] Thereafter, as illustrated at block 212, a document parsing 
software utility reads the document(s), and creates, as depicted at block 214, a 
database of all storage elements in the document that are visible to a 
microcontroller, such as, for example, controller 103 of data processing system 
100 illustrated in FIG. 1. Next, as depicted at block 216, an RTL code auto- 
generator can be utilized to create HDL code file(s). The acronym "HDL" 
generally refers to "Hardware Description Language". The process continues, as 
indicated at continuation block 218 in FIGS. 2 and 3. 

[0030] As illustrated thereafter at block 220 of FIG. 3, the software code 
auto-generator can create software file(s) that contain definitions and 
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declarations for every storage element and for every bit field within registers, 
strictly as defined in the hardware document specification. Next, as indicated at 
block 222, the software code auto-generator can create tables utilized by 
Power-On Self Test Code to check the hardware upon power-up. The use of 
the auto-generated software code ensures that the RTL hardware description 
complies with the hardware specification document. 

[0031] In accordance with one embodiment of the present invention, two 
code auto-generators can be implemented, including the hardware RTL code 
generator and the software code generator. Block 216, for example, refers to 
hardware code. Blocks 220-222, on the other hand, refer to software code 
which is not RTL code. In accordance with one possible embodiment of the 
present invention, such code may be C or C++ code. It can of course be 
appreciated by those skilled in the art that C or C++ code is not considered a 
limiting feature of the present invention, because other types of programming 
code can also be utilized to implement embodiments. 

[0032] The use of the auto-generated software code for storage elements 
and the Power-On Self Test tables causes the software to fail if the hardware 
does not comply with the specification document. Thus, as depicted at block 
224, a test can be performed to determine if the hardware complies with the 
specification document. If so, then the hardware design is verified, as indicated 
at block 228. If not, then the hardware design fails, as indicated at block 226. 
The process then terminates, as depicted at block 230. 

[0033] When implementing a method and/or system for verifying 
hardware designs against a hardware specification document, files can be 
organized according to a layered structured. Such a layered structure can be 
implemented as firmware and may include hardware drivers, which are based 
on code that actually manipulates hardware register bits or memory. These 
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drivers can be contained in the context of one or more files that hold only code 
that affects the specific hardware in question. A hardware driver generally is 
composed of both initialization code, and the actual driver code. The layered 
structure can also include configuration code that loads data and then acts as a 
ROM (read only memory) for the remainder of the firmware operations. 

[0034] Additionally, such a layer structure can include definitions that are 
specific to an external standard, such as, for example, the SAS or SCSI bus 
standards. These definitions can be contained in header files that hold 
definitions specific to that standard. The layered structure can also include 
operating system header and code files that exist to contain definitions and 
declarations utilized by a kernel to control the general flow of the software. 
These include all general code files that contain common definitions and 
declarations. Additionally, the layer structure can include development code 
files are files that contain code utilized for debugging. Code that facilitates 
retargettable Output for tracing or any other functions that are not part of the 
actual firmware can be contained within such code files. 

[0035] In accordance with an embodiment of the present invention, the 
interface for each separately specified block of hardware can be contained 
within its own code file set. The intent of this action is to provide a hardware 
abstraction layer so that if any part of the hardware is upgraded or redesigned in 
a later generation of the chip, code changes are limited to only the files owning 
that hardware interface. 

[0036] The files can contain the following: <HW Block Name>.h. This file 
contains the interface between the hardware and the rest of the firmware. Such 
a file can include prototypes for any functions that are owned by the hardware 
interface and that are visible to other parts of the firmware (e.g.., a driver API). 
This also includes 'extern' declarations for any constants that are owned by this 
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hardware interface but that must be visible elsewhere. 

[0037] The files can also contain <HW Block Name>.c. This file contains 
the code that directly manipulates the hardware. This includes declarations for 
all private functions, variables, block-owned registers, and constants. This also 
includes definitions for all public functions and for constants declared 'extern* in 
the .h file. 
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Table 1. Hardware Driver Files 



[0038] In accordance with an embodiment, code architecture can be 
implemented to include an infinite loop, event handlers, and interrupt handlers. 
The kernel code which implements the architecture can be contained in the 
main.c and global.c/h files. This includes event handling code and various other 
general utilities that are used by other code but are not hardware-specific. 

[0039] A Power On Self Test (POST) can be implemented in accordance 
with embodiments of the present invention and may possess special capabilities 
due to a UNIX executable aspect of the compiled code that would not be 
available if this were truly loadable firmware. A number of data structures can 
be used in the POST, including a Register Block Space Table, which comprises 
an Array storing the size of the address space for each register block. Such a 
table can be utilized to test the reserved spaces for unspecified storage 
elements. Registered addresses can be also utilized in the POST as a list of 
number defined literals utilized in other tables. A "Go Mask Table" can also be 
utilized with the post, which comprises an array that contains an entry for every 
register that contains a GO bit. 

[0040] Each entry will contain the address of the register and a mask with 
zeroed bits where GO bits exist. Go bits are specified in the hardware 
specifications by the letters "Go" at the end of the bit name. Additional data 
structures include a Power-On Reset Value Table (POR VTable) and a "Write 
Bits table." A POR VTable can be implemented as an array organized by 
register within register block. Each entry contains the register's address, the 
POR specification for the register, and a mask value that contains zeroed bits 
wherever the hardware specification indicates that the POR value is unknown. 
A "Write Bits Table" can be configured as an array organized by register within 
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register block. Each entry can contain the register's address and a mask value 
that contains zeroed bits wherever the hardware specification indicates that a 
non-writeable bit exists. A writeable bit can be defined as a bit that reads back 
what was written. 

[0041] An "On Chip RAM Information Table" can also be utilized with the 
POST in the form of an array for storing a word size (in 32-bit unsigned long 
values), number of words, and a mask for each entry in each on-chip RAM. The 
mask can include two unsigned long values with zeroed bits where no storage 
exists. Such a format can be utilized to determine the actual width of an entry in 
the RAM when the RAM has a non-DWORD word width. An FBUF internal 
buffer, for example, can be 34 bits wide, and is therefore listed as possessing 2 
32-bit entries per word. The MS mask can be set, however, to 0x00000003 to 
indicate that only two bits in the MS 32-bit entry are real. 

[0042] In general, the top level POST program simply calls the CPU 
initialization program and then calls for a POST. The POST can verify the 
functionality of the hardware in the following order: 1. Test Power-On Reset 
(POR) values of registers; 2. Test Write/Read capabilities of registers; 3. Test 
Interrupts; 4. Test On Chip Memory; 5. Test Off-Chip Memory; and 6. Run any 
automated tests existing in the hardware design (i.e., referred to here as an 
RTEST). 

[0043] In order to handle exceptions to the standard write-then-read 
verification test, and in order to allow the skipping of this test on bits where 
toggling would be a critical error, such as "Go" bits, the "GoBitTable" can be 
utilized. The POST will also test reserved register locations. Ideally these 
would read back zero and would not return what is written. For each address 
location in each register block, the following algorithm can be followed: 
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1 . If the location exists in the Avoid table then skip it and continue to the next location. 

2. Set the Go mask to OxFFFFFFFF. 

3. If the location contains a register then get the WriteBits mask from the Write Bits Table. 

4. Else set the Write Bits mask to OxFFFFFFFF. 

5. If the location is in the Go Mask table then get the Go mask value. 

6. If the Write Bits mask is zero then continue to the next location. 

7. Read the register's current value. 

8. XOR the read value with the Write Bits mask; AND the results with the Go mask. 

9. Write to the register. 

10. Read the register, AND this value with the Write Bits and Go mask. 

1 1 . Check the masked read value with the masked write value. 

12. If the values do not match then FAIL to log file. 

13. If the read value is non-zero and no register exists then FAIL to log file. 

[0044] An interrupt verification function can be implemented in 
accordance with an embodiment, which masks and clears all interrupts and sets 
the interrupt polarity to high. The interrupt verification function can then register 
an interrupt handler (IntlSRO) function with the compiler, call a function 
(PostTriggerlnt()) to force each interrupt, and then reregister the "real" ISRs for 
actual firmware operation. The PostTriggerlnt() function may cause an interrupt 
by setting up a "watch dog" timer interrupt to trigger an interrupt signal. The 
lntlSR() function sets a flag to show which interrupt occurred and then masks 
and clears the processor's interrupt logic. 

[0045] An On-Chip Memory Verification can be implemented as a 
function that can test the on-chip memories specified in the hardware 
specification. The On-Chip Memory Verification function can cycle through 
each on-chip memory and performs the following several tests, including writing 
incrementing or decrementing byte values to every location, then read back and 
verify. Other tests include, for example, writing OxAAAAAAAA to every location, 
and then reading back and verifying. Another test can include writing 
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0x55555555 to every location, then read back and verify. In the first three tests 
the memory location directly below and above the indicated memory block 
space is also written and read to verify that it does NOT contain valid memory. 

[0046] An on-chip memory verification function can be utilized to write or 
read a single on-chip memory location. Such a function when reading 
compares the value with the expected value (i.e., a parameter). This returns a 
FAIL message or command if the address is valid. The read value does not 
compare, however, if the address is invalid. The case, the data is compared. 

[0047] The Off-Chip Memory Verification function can perform a particular 
number of operations. First Off-Chip Memory locations in the window can be 
written, as specified by auto-generated write test table entries. Second, the Off- 
Chip Memory values can be read and compared using the configurations 
designed according to step one above. Crosstalk in the off-chip data lines can 
be checked with an operation that performs a write of traveling 1's to the off-chip 
memory starting at location zero. Finally, the off-chip memory values can be 
read and compared to the off-chip memory values written via step 3 listed 
above. 

[0048] Hardware auto-test (RTEST) logic can be implemented as 
hardware designed specifically to test a hardware block automatically. The 
RTEST portion of the POST simply sets up the RTEST logic and then starts the 
hardware test. The POST code handles any interrupts generated by the 
RTEST logic. Any of the aforementioned tests may generate POST warnings or 
failures. Warnings will not stop the POST, but can cause the POST to return a 
nonzero value. Errors can halt the POST function and cause the firmware to 
trap. 
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[0049] Based on the foregoing, it can be appreciated that embodiments 
of the present invention, as disclosed herein, are directed toward methods and 
systems for verifying a hardware specification of integrated circuit (IC) designs. 
Embodiments also include methods and systems for automatically verifying a 
hardware design based on a hardware specification document. As indicated 
herein, a plurality of predefined elements can be designed within a hardware 
specification document, such that the hardware specification document provides 
a hardware design for a hardware device. 

[0051] The predefined elements can be stored within a database of 
hardware components, wherein each predefined element of the predefined 
elements is associated with a hardware component of the hardware device. 
Physical components of the hardware device can be compared with the 
predefined elements maintained within the database of hardware components 
upon an initial power-up of the hardware device in order to verify that the 
hardware device functions according to the hardware specification document. 

[0052] An RTL auto-generation utility or module generally auto-generates 
define statements utilized by the RTL code to decode and configure the 
hardware memories and registers. The software auto-generation utility or 
module auto-generates the same define statements utilized by the software 
code. The POST software auto-generation utility or module, as indicated 
earlier, can then auto-generate table-based tests that can verify the accessibility 
and correctness of the on-chip memories, off-chip memories, and registers as 
specified in the IC specification document. 
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[0053] Note that embodiments of the present invention can be 
implemented in the context of a "module" or "modules". In the computer 
programming arts, for example, a module can be typically implemented as a 
collection of routines and data structures that performs particular tasks or 
implements a particular abstract data type. Modules can be composed of two 
parts. First, a software module may list the constants, data types, variable, 
routines and the like that that can be accessed by other modules or routines. 
Second, a software module can be configured as an implementation, which can 
be private (i.e., accessible perhaps only to the module), and that contains the 
source code that actually implements the routines or subroutines upon which 
the module is based. Thus, for example, the term module, as utilized herein 
can refer to a software module(s) or implementations thereof. Such modules 
can be utilized separately or together to form a program product that can be 
implemented through signal-bearing media, including transmission media and 
recordable media. 

[0054] Examples of suitable modules which can be implemented in 
accordance with embodiments of the present invention include a comparing 
module, a testing module, an RTL auto-generation module, a software auto- 
generation module, and the like. The comparing module, for example, can 
automatically compare physical components of the hardware device with the 
predefined elements maintained within the database of hardware components 
upon an initial power-up of the hardware device, in order to verify that the 
hardware device functions according to the hardware specification document. 

[0055] The testing module, for example, can automatically force the 
hardware device to fail if the hardware device does not comply with the 
hardware specification document, in response to automatically comparing 
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physical components of the hardware device with the predefined elements 
maintained within the database of the hardware components upon an initial 
power-up of the hardware device. The RTL auto-generation module can 
generate define statements utilized by an RTL code to decode and configure at 
least one hardware memory and at least one register thereof. The software 
auto-generation module can auto-generate the same set of define statements 
utilized by the software code thereof. 

[0056] The embodiments and examples set forth herein are presented to 
best explain the present invention and its practical application and to thereby 
enable those skilled in the art to make and utilize the invention. Those skilled in 
the art, however, will recognize that the foregoing description and examples 
have been presented for the purpose of illustration and example only. Other 
variations and modifications of the present invention will be apparent to those of 
skill in the art, and it is the intent of the appended claims that such variations and 
modifications be covered. 

[0057] The description as set forth is not intended to be exhaustive or to 
limit the scope of the invention. Many modifications and variations are possible 
in light of the above teaching without departing from the scope of the following 
claims. It is contemplated that the use of the present invention can involve 
components having different characteristics. It is intended that the scope of the 
present invention be defined by the claims appended hereto, giving full 
cognizance to equivalents in all respects. 
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